COMMENT ⊗   VALID 00003 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	/SUBJECT
C00007 00003	/SUBJECT
C00012 ENDMK
C⊗;
/SUBJECT
common-lisp-object-system
Altering Generic Functions

It seems there are three proposals for the primitives used for modifying
generic functions. I will refer to the parts of generic functions as
`facets.'  Assuming that all of the facets discussed in the current draft
specification are accepted, the modifiable facets are:
argument-precedence-order, generic-function-class, interface,
method-arguments, method-class, and method-combination-type.  Here are the
proposals:

1. There is a series of facet accessors, each accessor naming a SETFable
place.

2. There is a function named MODIFY-GENERIC-FUNCTION that takes a required
generic function argument followed by the same keyword arguments that
MAKE-GENERIC-FUNCTION accepts.  Furthermore, there is a function, possibly
named GENERIC-FUNCTION-FACETS, that returns six values, one for each
modifiable facet.

3. MAKE-GENERIC-FUNCTION accepts a keyword argument that is a generic
function to be updated from the other arguments. In addition there is
function, possibly named GENERIC-FUNCTION-FACETS, that returns six values,
one for each modifiable facet.

Here are the advantages and disadvantages of each, as I see them.

1. There are six new function names, one for each modifiable facet.
Because these functions simply are accessors to parts of some larger
object, this requires knowing about many function names. Changing the
facets, though, only requires knowing that the accessors are SETFable.

2. One new function is added, but with six keywords to remember. These
keywords are the same as the keywords for MAKE-GENERIC-FUNCTION, so the
additional cognitive overhead is low. There is a new function that returns
six values, and the order of the values will be difficult or impossible to
remember.

3. This option is very much like number 2, but the name of the function is
misleading - one is not making a generic function, one is altering some of
its characteristics.

Contrasting option 1 with options 2 and 3, the choices we face are similar
to those faced earlier with the sequence functions in Common Lisp.  The
two basic choices were: a large series of independent functions or a
smaller series with a set of keyword arguments. The Common Lisp designers
chose the keyword route.

The analogy breaks down here because we require a complex informational
function, GENERIC-FUNCTION-FACETS, which is needed to find out the current
facets of a generic function. Without it, it is not possible to modify
programmatically some facets of one generic function to be the same as
those of another.

Therefore, I favor option 1.

Larry Masinter suggsted something interesting. Generic functions could be
defined to be instances of a generic-function class. Therefore, these six
facets are simply `slots' defined by the generic-function class; instances
have these `slots,' and they are naturally SETFable.

			-rpg-
/SUBJECT
common-lisp-object-system
Altering Things

Larry's comments bring up the issue of how far we want to take the
meta-class concept in this specification. The standard-type-classes have a
different meta-class from those of DEFCLASS. DEFCLASS is somewhat like
DEFSTRUCT in that it defines an instance structure with slots in which
values may be stored.

As Larry points out, generic functions can made instances of a generic
function class whose meta-class directs the creation of `slot accessors
and updators' that modify facets of the precise sort thing that generic
functions happen to be in some implementation.

Thinking of these facets as slots is quaint, in the same way that one can
think of the `mantissa' and `exponent' as slots in a floating-point number.
Of course, with meta-objects this can done. I say this is `quaint' because
it is promulgating a misnomer of sorts, the misnomer of referring to the
subparts of eveything as `slots.' 

It is the class of CLASS that defines `slots.' It would be the class of
FLOATING-POINT-CLASS that would define `mantissa' and `exponent.' We would
be taking the terminolgy specific to DEFCLASS-style classes and misapplying
it in talking about floating-point numbers.

We will recommend to X3J13 that they split DEFSTRUCT into DEFCLASS and
DEFRECORD, which makes sense. When we try to think of floating-point
numbers as instances of classes, and when we break floating-point numbers
into mantissas and exponents, we are making the classes into
record-structure-defining objects. Similarly, thinking of generic functions
as objects whose `slots' are SETFable, we are using the DEFCLASS terminology
to impose some record structure on top of generic functions.

Smalltalk takes seriously the approach I'm hinting at, and possibly we
want to take it seriously as well. The simple class CLASS approach we in
fact take is a simplfication of the whole-hog, Smalltalk approach.

			-rpg-